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Background of the Invention 

The present invention generally relates to packet-based switching systems, and 
more particularly to methods, apparatuses, mediums, and signals for facilitating the 
transmission of data packets having diverse formats through switching systems. 

Description of the Relevant Art 

A number of different packet-based data transmission protocols are in commercial 
use. While packet-based switching systems dedicated to particular protocols are 
common, it has been more difficult to produce general packet switching systems that are 
able to switch multiple protocols. This is partially due to the diverse formats of the data 
packets used by the various protocols. 

Summary of the Invention 

Embodiments of the present invention described and shown in the specification, 
claims, and drawings facilitate the transportation of data packets having diverse formats 
through general packet switching systems. 

An object of the present invention is to provide a uniform format for 
encapsulating the diverse data packet formats generated by various packet-based data 
transmission protocols. An advantage of the present invention is the improvement in 
switching efficiency resulting from the use of the particular embodiments of uniform data 
packet encapsulation formats of the present invention. 
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In some embodiments of the present invention a frame (also referred in this 
specification as a "Unified Data Packet") is stored in the computer-readable medium of 
computer systems, including packet-switching computer systems, or is transported on 
communications systems between or within computer systems. A particular embodiment 
5 of the Unified Data Packet of the present invention is referred to in this specification as 
the "Fairfax Frame." Embodiments of the Unified Data Packet comprise a Header 
Section, a Payload Section, and a Trailer Section. The Header Section comprises a 
Segment Type field and a Final Payload Count Valid field. The contents of the Segment 
Type field and the contents of the Final Payload Count Valid field are responsive to the 

10 contents of the Payload Section. The Header Section may also comprise a Service Type 
field, a Routing Identification field, and/or a Source Identification field. Embodiments of 
the Unified Data Packet may further comprise, responsive to the contents of the Final 
Payload Count Valid field, a Final Payload Count field in the Payload Section. Complete 
or partial data packets for transport using the Unified Data Packet of the present invention 

15 are stored in the Payload Section. Furthermore, the Unified Data Packet of the present 
invention may comprise two Header Sections, each with an associated Payload section. 

Additional objects and advantages of the invention are set forth in part in the 
description which follows, and in part are obvious from the description, or may be learned 
by practice of the invention. The objects and advantages of the invention may also be 
20 realized and attained by means of the instrumentalities and combinations particularly set 
out in the appended claims. 

Brief Description of the Drawings 

The accompanying drawings, which are incorporated in and constitute part of the 
specification, illustrate preferred embodiments of the invention, and together with the 
25 description, serve to explain the principles of the invention. 

In the accompanying drawings: 

FIG. 1 is a diagram depicting an embodiment of a Unified Data Packet of the 
present invention for encapsulating data packets having diverse formats. 

FIG. 2 is a diagram depicting an embodiment of a Fairfax Frame of the present 
30 invention. 
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FIG. 3 is a diagram depicting an embodiment of a Header Section of a Fairfax 
Frame of the present invention. 

FIG. 4 is a diagram depicting an embodiment of a Payload Section of a Fairfax 
Frame of the present invention. 

5 FIG. 5 is a diagram depicting an embodiment of a Trailer Section of a Fairfax 

Frame of the present invention. 

FIG. 6 is a diagram depicting an embodiment of a Fairfax Dual Routing Packet of 
the present invention. 

Detailed Description 

1 0 Interpretation of Terms 

Unless otherwise noted in this specification or in the claims, all of the terms used 
in the specification and the claims will have the meanings normally ascribed to these 
terms by workers in the art. Certain terms specifically comprise the meanings associated 
with them as follows: 

15 "Computer system" refers to individual standalone computers, multiple computers 

coupled in any manner, and software simulations of computers regardless of the intended 
use of the computer system or the technology used to implement the computer system. 
The term "Computer system" includes, but is not limited to, packet-switching systems 
and other communications switching systems. 

20 "Data packets" refers to any data packets used by any computer communications 

protocol, and includes synchronous (including Time Division Multiplex (TDM)) data 
packets and asynchronous (including High Level Data Link Control (HDLC)) data 
packets. 

Detailed Description 

25 Acts performed by methods and apparatus functions of the present invention may 

be implemented, as is known in the art, as software running on general purpose computers 
or special purpose computers, as hardware, or as combinations of software and hardware. 
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The data packets produced by various computer communications protocols 
generally vary widely in format, including size. Due to this non-uniformity, it may be 
difficult and inefficient to switch data packets having diverse formats through a general 
purpose packet switch. The present invention facilitates such switching by encapsulating 
5 all of the data packets to be switched (sometimes referred to as "transported data packet") 
into a Unified Data Packet format. Embodiments of the Unified Data Packet contain a 
Header Section, a Payload Section, and a Trailer Section. These embodiments are 
uniform in overall size, and in the arrangement and purpose of the data fields contained in 
the Header Section and Trailer Section. The arrangement of the Payload Section, which 
10 carries all or a portion of a data packet to be switched, varies, as described below, 
depending on the data packet being carried. The uniform size of the Unified Data Packet, 
and the generally uniform arrangement and purpose of the fields within the Unified Data 
Packet enables Unified Data Packets to be switched efficiently. 

In the embodiment of Unified Data Packet 101 depicted in FIG. 1, Unified Data 
15 Packet 101 comprises Header Section 105, Payload Section 110, and Trailer Section 115. 
Embodiments of Trailer Section 115 comprise the various fields used for routing and 
managing data packets and contained in data packet trailers as are known in the art. In 
some embodiments of the present invention, for example, Trailer Section 115 will contain 
a single field used in conjunction with error checking, as is known in the art, such as a 
20 checksum or a Bit Interleaved Parity value. 

In some embodiments, depending on the size of the transported data packet and as 
described below in connection with the Final Payload Count Valid Field, Payload Section 
110 comprises a single, fixed-length field containing all or part of a transported data 
packet; while in other embodiments Payload Section 110 comprises a fixed-length Final 
25 Payload Count field 1 1 1 in addition to a fixed-length field containing all or part of a 
transported data packet. 

Embodiments of Header Section 105 comprise the various fields, as are known in 
the art, for routing and managing data packets. Embodiments of Header Section 105 also 
comprise fields for indicating Segment Type and Final Payload Count Valid. If a 
30 transported data packet is of exactly the same length as fixed-length Payload Section 110, 
then the Segment Type field is set to indicate that Payload Section 110 contains a 
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complete transported data packet and the Final Payload Count Valid field is set to indicate 
that Payload Section 110 does not contain a Final Payload Count field 111. If a 
transported data packet is smaller than the fixed-length Payload Section 110, then the 
Segment Type field is set to indicate that Payload Section 110 contains a complete 
5 transported data packet, the Final Payload Count Valid field is set to indicate that 
Payload Section 110 contains a Final Payload Count field 111, and the Final Payload 
Count field 1 1 1 contains the length of the transported data packet. 

If a transported data packet is larger than the fixed-length Payload Section 110, 
then the transported data packet must be transported by two or more Unified Data Packets 

10 101. In the Unified Data Packet 101 containing the initial portion of the transported data 
packet, the Segment Type field is set to indicate that Payload Section 110 contains the 
initial part of the transported data packet and the Final Payload Count Valid field is set to 
indicate that Payload Section 110 does not contain a Final Payload Count field 111. In 
the Unified Data Packet 101 containing a middle part of the transported data packet, the 

15 Segment Type field is set to indicate that Payload Section 110 contains a middle part of 
the transported data packet and the Final Payload Count Valid field is set to indicate that 
Payload Section 110 does not contain a Final Payload Count field 111. Some 
embodiments of Header Section 105 will contain a Sequence Number field, as is known 
in the art. hi some embodiments, the Sequence Number field is set to zero in a Unified 

20 Data Packet 101 containing a complete or initial part of a transported data packet. The 
Sequence Number field is incremented by one in each subsequent Unified Data Packet 
101 containing a middle part or final part of a transported data packet. Thus, the initial, 
middle, and final portions of a transported data packet will contain sequential numbers in 
the Sequence Number fields of the Unified Data Packets 101 carrying the transported data 

25 packet and the order of the portions can be determined, as is known in the art, so that the 
transported data packet portions can be extracted from the Unified Data Packets 101 and 
correctly reassembled. Other methods of determining the correct order of packets sent 
through communications systems are known in the art and may be employed. 

Finally, in the Unified Data Packet 101 containing the final part of the transported 
30 data packet, the Segment Type field is set to indicate that Payload Section 110 contains 
the final part of the transported data. If the final part of the transported data packet is 
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smaller than the fixed-length Payload Section 110, then the Final Payload Count Valid 
Field is set to indicate that Payload Section 110 contains a Final Payload Count field 111, 
and the Final Payload Count field 111 contains the length of the final part of the 
transported data packet. If the final part of the transported data packet is the same size as 
the fixed-length Payload Section 110, then the Final Payload Count Valid Field is set to 
indicate that Payload Section 1 10 does not contain a Final Payload Count field 111. 

A detailed example of one embodiment of the present invention is provided as 
follows: 

Fairfax Frame 201 

The Fairfax Frame is the Ocular Networks, Inc., (ONI) Fairfax, VA, proprietary 
format for encapsulating user Time Division Multiplex (TDM) traffic, Asynchronous 
Transfer Mode (ATM) Cell or IP packet, configuration information, and Operation, 
Administration and Maintenance (OA&M) information into a packet to be switched 
through a packet-based switching fabric. Ocular products using the Fairfax Frame are 
referred to herein as "Ocular Switching Equipment." An exemplary format for a Fairfax 
Frame 201 is shown in FIG. 2. Fairfax Frame 201 comprises a Fairfax Header Section 
205, which is 8 bytes in size, a Fairfax Payload Section 210, which is 63 bytes in size 
(including one byte for Final Payload Count field 111), and a Fairfax Trailer Section 215, 
which is one byte in size. 

Fairfax Header Section 205 

The header fields are as depicted in FIG. 3 and described in more detail below. 

Version 301 
Size: 1 bit. 

Usage: The Version (VER) field 301 is provided to permit future 
upgrades to the Fairfax Frame 201 format. 



Value 


Description 


0 


Version 0 - initial value. 


1 


Version 1 or higher - future value. 
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The field is loaded at every place where Fairfax Frames 201 are generated, and 
checked at every place where Fairfax Frames 201 are received and interpreted: 

• All Ocular switching equipment must recognize and interpret a 
Version 0 frame. 

• Version 1+ equipment can use the bit to determine the Fairfax Frame 
201 capability of the generating equipment. 

• If Version 0 compatible equipment receives a Version 1+ frame, the 
frame should be counted and discarded. 

The VER field 301 is only one bit because a Version 1+ Fairfax Frame 201 can 
define additional version bits to accommodate further frame versions. 

Unused Values : There are no unused values. 

Multicast 302 

Size: 1 bit. 

Usage: The Multicast (MCST) field 302 indicates whether the frame has 
15 a single (unicast) or multiple (multicast) destination(s): 



Value 


Description 


0 


Frame is unicast, i.e. will be switched to a single 




egress port. 


1 


Frame is multicast, i.e. will be switched to multiple 




egress ports. 



The MCST field 302 will always be loaded when a Fairfax Frame 201 is created. 
However, the value may not be used since the frame's destination(s) will be identified by 
indexing a routing table with the Fairfax Routing ID. The MCST field 302 provides a 
20 direct indication of the multicast status for debugging purposes. 

Unused Values: There are no unused values. 

Segment Type 304 
Size: 2 bits. 
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Usage: The Segment Type (ST) field 304 indicates which part of a user 
datagram is carried in the Fairfax Payload section 210. The four values are interpreted as 
follows: 



Value 


Description 


10 


Beginning Of Frame (BOF) 


00 


Continuation Of Frame (COF) 


01 


End Of Frame (EOF) 


11 


Single Segment Frame (SSF) 



5 BOF, COF and EOF are applied to Fairfax Frames 201 which carry part of a 

segmented datagram. SSF is applied to a Fairfax Frame 201 which carries a complete user 
datagram. 

When a segment type error is detected, the erroneous segment should be counted 
and discarded. 

10 Unused Values : There are no unused values. 

Final Payload Count Valid 303 
Size: 1 bit. 

Usage: The Final Payload Count Valid (FPCV) field 303, together with 
the header ST field 304 and the first byte of the Fairfax Payload section 210 (known as 
15 the Final Payload Count (FPC) 111), indicates the number of valid data bytes in the 
payload section: 



ST 
Value 


FPCV Value 


Description 


BOF 


0 


User datagram information completely fills the Fairfax 
Payload section 210. 




1 


Invalid, a BOF segment must contain a full payload. 
When such a frame is detected it should be counted and 
discarded. 


COF 


0 


User datagram information completely fills the Fairfax 
Payload section 210. 




1 


A user datagram error has been detected at the ingress 
to the network and no further segmentation of the 
datagram will be performed. 
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ST 






Value 


FPCV Value 


Description 


EOF 


0 


The end of the user datagram completely fills the entire 
Fairfax Payload section 210. 




1 


The FPC field 111 contains a count of the number of 
payload bytes (1-63) which contain the end of the user 
datagram. 


SSF 


0 


The user datagram completely fills the entire Fairfax 
Payload section 210. 




1 


The FPC field 1 1 1 contains a count of the number of 
payload bytes (1-63) which contain the entire user 
datagram. 



The FPCV field 303 prevents the need to add a segment to a datagram just to carry 
the payload count for a full Fairfax Payload section 210. 

This scheme only supports user datagrams which are an integer number of bytes 
5 in length. 

Unused Values: There are no unused values. 

Sequence Number 305 
Size: 3 bits. 

Usage: The Sequence Number (SN) field 305 provides protection for 
10 datagrams segmented into multiple Fairfax Frames 201 : 

• When a user datagram is segmented, the SN field 305 in each 
consecutive frame is set to an incrementing, modulo 8 number (0 - 7, 
0 ...). The SN field 305 will be set to 0 (zero) for the first frame of 
every datagram. 

15 • When a frame carries a complete user datagram, the SN field 305 is set 

to zero. Any other SN value is invalid. 

• Some system implementations cannot transmit or receive Fairfax 
Frames 201 out of order. Therefore an error in the Fairfax Frame SN 
field 305 indicates a dropped frame. When a Fairfax Frame sequence 

20 number error is detected, the erroneous frame should be counted and 

discarded. 
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Unused Values: There are no unused values. 

Reserved 306 

Size: 8 bits. 

Usage: The Reserved (RES) field 306 is available to increase the size of 
5 the Fairfax Routing Identifier fields 307, 308 and/or include additional control fields in 
future versions of the Fairfax Frame format. At the time of writing, the field is unused 
and the value will be set to 00H. 

Unused Values: RES values of 01H-FFH are currently invalid. Until the 
field usage is defined, frames with invalid RES values should be counted but not 
10 discarded. The counter should include an enable/disable function so that future versions 
of the Fairfax Frame 201 can implement a RES field value of 00H without being counted. 

Fairfax Header 205 contains an additional reserved field 313. This field is not 
currently used. 

Fairfax Routing Identification 307, 308 
15 Size: 16 bits. As would be understood by one skilled in the art, the 

Fairfax Routing Identification (FRID) value is located in two fields --FRID field 307 
contains the Most Significant Byte (MSB); FRID field 308 contains the Least Significant 
Byte (LSB). 

Usage: The FRID fields 307, 308 identify the frame's path through the 
20 Ocular switching equipment between the ingress and egress ports. 

Fairfax Routing Identification (FRID) in the Fairfax header provides the logical 
routing information for transporting the payload from an ingress port to an egress port. 
Multiple FRIDs can be assigned to one ingress port for establishing multiple connections 
to several different egress ports. 

25 The FRID is a 'Virtual" value which represents a unidirectional path through the 

Ocular switching equipment from an ingress port to an egress port. A bi-directional path 
through the Ocular switching equipment will have two FRID values assigned, one for 
each direction. 
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When the Ocular switching equipment needs to determine the details of the 
frame's path (e.g. identify the ingress and egress ports) the FRID value will index into 
routing table(s) which will return the required results, as is known in the art. 

The 16-bit FRID fields 307, 308 can identify a maximum of 65,536 unidirectional 
5 paths or 32,768 bi-directional paths through the Ocular switching equipment. For TDM 
ports which encapsulate multiple Digital Signal level Is (DSls), there is one FRID 
assigned to each DSL This value represents the ingress port, egress port and the location 
of the DS1 within the encapsulating egress datagram. 

Unused values: Frames with unused FRID values will be counted and 

10 discarded. 

Datagram Reassembly Identification 

Together with the First in First Out (FIFO) data transfer mechanism used to pass 
datagrams through the Ocular switching equipment , the FRID 307, 308, ST 304, and SN 
305 fields provide sufficient datagram identification to permit an egress Input Output 
1 5 Board (IOB) to reassemble multiple segmented datagrams from multiple ingress IOBs. 

At any one time, an egress IOB can only be reassembling one datagram from each 
Ocular switching equipment ingress port. The FRID fields 307, 308 identify the source 
port (and so the original datagram) and the ST 304 and SN 305 fields identify the 
constituent segments. Note that a multicast datagram may be simultaneously reassembled 
20 once on each of multiple egress IOBs. 

Source Slot Identification 309 
Size: 5 bits. 

Usage: The Source Slot Identification (SSID) field 309 identifies the 
switching system chassis and slot which generated the Fairfax Frame 201. 
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Bit 


Description 


4 


Identifies the chassis. A 0 (zero) identifies the first, or 
only chassis. A 1 (one) identifies the second chassis in a 
two-chassis installation. 


3-0 


Identifies the slot within the chassis. A chassis will hold 
up to 14 IOBs and two NCBs, with both types of boards 
capable of generating Fairfax Frames 201. 



The SSID field 309 will always be loaded when a Fairfax Frame 201 is created. 
However, the value may not be used by any switching system function since the frame's 
source slot will be identified by indexing a routing table with the FRID 307, 308. The 
5 SSID field 309 provides a direct indication of the switching system source slot for 
debugging purposes. 

Unused Values: Since the number of installed chassis, Network Control 
Boards (NCBs) and IOBs is variable, determination of valid slot values will be 
configured. Frames with invalid SSID values will be counted and discarded. An NCB 
10 provides the control and switching functions to interconnect the traffic between IOBs. 

Source Port Identification 310, 311 

Size: 5 bits. As would be understood by one skilled in the art, the Source 
Port Identification (SPID) value is located in two fields — SPID field 310 contains the 
Most Significant Byte (MSB); SPID field 3 1 1 contains the Least Significant Byte (LSB). 

15 Usage: The SPID fields 310 and 311 identify the port that generated the 

Fairfax Frame 201. The field value is local to each IOB or NCB and starts counting from 
0 (zero) for the first port. 

For IOB-sourced frames, the lowest numbered SPID values refer to the physical 
ports on the board. Port number 3 1 is assigned to test/debug frames generated from the 
20 supervisory processor. 

All NCB-sourced frames are generated by the supervisory processor and so will 
be assigned to port number 3 1 . 

The SPID fields 310 and 311 will always be loaded when a Fairfax Frame 201 is 
created. However, the value may not be used by any switching system function since the 
25 frame's source port will be identified by indexing a routing table with the FRID. The 
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SPID fields 310 and 311 provide a direct indication of the switching function source port 
for debugging purposes. 

Source Port Identification (SPID) and Source Slot Identification (SSID) provide 
the information on where the Fairfax frames originated (frame origination location). It 
5 can provide information for troubleshooting. For example, SPID, SSID together with 
Forward Tagging can allow an egress port quickly to identify the source of congestion. 

Unused Values: The currently identified IOBs have at most 28 ports (on 
the DS1 IOB). Therefore SPID values of 28-30 are unused but could be used in the future. 
All remaining SPID values will be configured based on the type of IOB or NCB. Frames 
1 0 with invalid SPID values will be counted and discarded. 

Discard Priority 312 
Size: 1 bit. 

Usage: The Discard Priority (DP) 312 field is used in congestion 
situations, where it indicates the discard priority for the frame. 

15 A value of 1 (one) indicates that the frame is discard priority, a value of 0 (zero) 

indicates that the frame is not discard priority. In a congestion situation, discard priority 
frames will be discarded in preference to non-discard priority frames. 

At an ingress port, any discard priority indication included in the incoming 
datagrams will be copied into the DP bit 312. At an egress port, the DP bit 312 will be 
20 copied into the appropriate datagram field. 

The DP bit 312 can be set by the datagram originator, by preceding network 
elements, or anywhere within the Ocular switching equipment where policing is being 
performed. 

Unused Values: There are no unused values. 

25 Forward Tag 315 

Size: 1 bit. 
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Usage: Forward Tag Congestion Notification or "Forward Tagging" 
(FT AG) 315 is set to 1 (one) by the Ocular switching equipment to indicate that 
congestion is being experienced for traffic in the direction of the Fairfax Frame 201 
carrying the FT AG 315 indication. Thus, FT AG 315 indicates to the frame destination 
5 that congestion was experienced along the frame's path through the Ocular switching 
equipment. 

At an ingress port, any congestion indications included in incoming datagrams are 
carried transparently through the Ocular switching equipment. The congestion values are 
not copied to the Fairfax header FT AG field 315. At an egress port, if the Fairfax header 
10 FT AG field 315 is set to 1 (one), the value will be copied into the appropriate outgoing 
datagram field to indicate congestion in the datagram path. 

The FT AG bit can be set to 1 (one) anywhere there is policing or queuing within 
the Ocular switching equipment. 

Unused Values: There are no unused values. 

1 5 Backward Tag Congestion Notification 314 

Size: 1 bit. 

Usage: Backward Tag Congestion Notification or "Back Tagging" 
(BTAG) 314 is set to 1 (one) by the Ocular switching equipment to indicate that 
congestion is being experienced for traffic in the opposite direction of the Fairfax Frame 
20 201 carrying the BTAG 314 indication. Thus, BTAG 314 indicates to the frame source 
that congestion was experienced for frames being transmitted by the source. 

At an ingress port, any congestion indication included in incoming datagrams are 
carried transparently through the Ocular switching equipment. The congestion values are 
not copied to the Fairfax header BTAG field 314. At an egress port, if the Fairfax header 
25 BTAG field 314 is set to 1 (one), the values will be copied into the appropriate outgoing 
datagram field to indicate congestion in the datagram path. 

The BTAG bit can be set to 1 (one) anywhere there is policing or queuing within 
the Ocular switching equipment. 
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BTAG is used within Ocular switching equipment to signal a need to reduce the 
amount of traffic being passed into the congested function. However, there are a number 
of issues with BTAG which may result in the field being deleted from the header: 

• Many protocols do not include a BTAG-type indication in their 
header/trailer fields. These protocols support sender data rate reduction 
by transmitting higher-layer protocol messages from the receiver, 
which receives the forward congestion indication, to the sender. 

• For those protocols which do support BTAG, the sender is not always 
required to reduce the transmitted datagram flow. 

• BTAG does not easily apply to multicast frames because some egress 
queues/ports may be congested and some may be uncongested. 

The BTAG field 314 has been located adjacent to the unused header bits, so that 
the fields can be merged in the event that BTAG is removed from the Fairfax Header 205. 

Unused Values: There are no unused values. 

Fairfax Service Identification 316 
Size: 8 bits. 

Usage: The Fairfax Service Identification (FSD3) field 316 identifies the 
type of datagram, type of service, or owner of the datagram carried in the payload section. 

Example datagram and service types are: 

• TDMDS1 

• Encapsulating Digital Signal level 0s (DSOs) 

• Clear channel 

• TDM Virtual Tributary VT1 .5 (VT1 .5) 

• TDM DS3 

• Encapsulating DS 1 s 

• Clear channel 
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• TDM Synchronous Transport Signal level 1 (STS-1) Synchronous 
Payload Envelope (SPE) 

• IP Access Concentration 

• IP encapsulation over Asynchronous Transfer Mode (ATM) 
Adaptation Layer 5 (AAL5) 

• ATM Multiplexing 

• Configuration 

• Operations Adminstration and Maintenance (OAM) 

When the FSK) identifies the owner of the payload data, e.g. an Internet Service 
Provider (ISP), the value represents a complete package of processing and prioritizing to 
be applied to the payload. 

Unused Values: Frames with unused FSID values will be counted and 

discarded. 

Fairfax Queue Identification 31 7 
Size: 8 bits. 

Usage: The Fairfax Queue Identification (FQID) field 317 identifies the 
egress queue/priority for the datagram carried in the payload section. 

Example queue/priority types include: 

• TDM Circuit Assurance 

• ATM Service Categories 

• Constant Bit Rate (CBR) 

• real time Variable Bit Rate (rt-VBR) 

• non-real time Variable Bit Rate (nrt-VBR) 

• Unspecified Bit Rate (UBR) 

• Configuration 
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• OAM 

• Transmit Last 

TDM Circuit Assurance is applied to TDM traffic. Frames with this FQID 
priority are transmitted to meet the DS1 and DS3 timing requirements through the Ocular 
switching equipment. 

QAM is applied to Ocular switching equipment internal traffic control which may 
need to be switched even in the event of user datagram congestion. 

Configuration is subdivided into at least two sub-priorities, code downloads 
(lower priority) and routing table updates (higher priority). 

Transmit Last is the lowest priority and is only transmitted from an egress queue 
when no other FQID types are present. 

In addition to these queue types, the FQID value assigned at the ingress port may 
reflect any priority values contained in the incoming datagram. 

Unused Values: Frames with unused FQED values will be counted and 

discarded. 

Fairfax Pay load Section 210 

The Fairfax Payload Section 210 is depicted in FIG. 4. 
Size: 63 bytes. 

Usage: The payload section carries the user datagram. 

If the datagram to be transferred is no larger than the payload section, the entire 
datagram is carried in one Fairfax Payload Section 210. 

If the datagram to be transferred is larger than the Fairfax Payload Section 210, 
the datagram will be segmented into multiple subframes. The subframes for a particular 
datagram may be transferred consecutively or interleaved with segments from other ports 
and/or IOBs, datagrams from the same port will not be interleaved.) Interleaving between 
ports is supported to allow ingress IOBs to send data to the associated egress IOB(s) as 
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the data arrives and fills the Fairfax Payload Sections 210, reducing the need to buffer 
complete datagrams before forwarding them. 

Unused Values; If a datagram does not completely fill the payload 
section, the unused bytes do not have to be set to 0 and can be any value. 

5 Final Payload Count 111 

Size: 8 bits. 

Usage: The Final Payload Count (FPC) field 111 contains a count of the 
number of payload bytes which contain user datagram information. 

If a datagram does not fill the entire payload section in the last, or only, 
10 (sub) frame then the header FPCV field 303 is set to 1 (one) and the first byte of the 
Fairfax Payload Section 210 becomes the Final Payload Count (FPC) field 111. This field 
contains a count of the number of payload bytes (1-63) which contain user datagram 
information. 

The unused payload bytes (potentially all but two bytes in the payload section) 
1 5 take up available bandwidth. 

If a datagram completely fills the last, or only, (sub)frame then the header FPCV 
field 303 is set to 0 (zero) and the first byte of the Fairfax Payload Section 210 is a valid 
datagram byte. 

Unused Values: 0 (zero) is unused because this indicates that the 
20 previous Fairfax Payload Section 210 was completely filled by the end of the datagram, 
64-255 are unused because they indicate more valid datagram bytes than fit in a Fairfax 
Payload Section 210. For all unused values, the frame will be counted and discarded. 

Fairfax Trailer Section 215 

The trailer section comprises a single field as depicted in FIG 5. 

25 Bit Interleaved Parity (8-bit) 501 

Size: 8 bits. 
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Usage: The Bit Interleaved Parity (8 bit) (BIP-8) field 501 contains the 
result of taking each frame header and payload byte and performing a parity calculation 
on each bit position as is known in the art. The BIP-8 value will reflect an odd parity 
calculation, i.e. the BIP-8 value will be set so the total number of ' V bits in each position 
5 is odd. 

When a BIP-8 error is detected, the frame will be counted and discarded. 

In another embodiment of the present invention, shown in FIG. 6, a Fairfax Dual 
Routing Packet 601 is provided. A Fairfax Dual Routing Packet 601 is a packet that 
carries two Fairfax Routing IDs (FRIDs) with their associated payloads. A First FRID 
(MSB) 607 and a First FRID (LSB) 608 are associated with a first payload 610. First 
FRID 607, 608 are part of first Fairfax header 605. A second FRID (MSB) 667 and a 
second FRID (LSB) 668 are associated with a second payload 630. Second FRED 667, 
668 are part of second Fairfax header 625. The original Fairfax payload is divided into 
two parts: the first part is for First Fairfax Header 605 and First Payload 610, and the 
second part is for Second Fairfax Header 625 and Second Payload 630. The remaining 
bytes of the 8-byte First and Second Fairfax Headers 605, 625 axe substantially the same 
as described above for Fairfax Header 205, as shown in FIG. 3. A code in the Service 
Type field (First FSID 643 and Second FSID 646) of the First and Second Fairfax 
Headers 605, 625 is used to indicate that the Fairfax packet is a Fairfax Dual Routing 
Packet. 

As an example, the Second Fairfax Header 625 is located starting from the 36th 
byte as shown in Figure 6. Because only a single segment frame is carried, no final 
payload count byte is required. In other words, each Header Section is followed by its 
Payload Section. 

25 By examining the Service Type field First and Second FSID 643, 646 in Headers 

605, 625, the Fairfax packet processor is able to identify each individual routing ID with 
its associated payload, and to route the two payloads 610 and 630 to separate destinations. 
In this embodiment, the size of a payload is a predetermined value that is in First and 
Second FSID 643, 646, such as 27 bytes. In this embodiment, the size of the payload is 
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specified in FSID 643, 646 rather than through FPCV 303. A Fairfax Trailer 615 is used 
that is the same as Trailer Section 215 depicted in FIG. 5. 

Conclusion 

It should be understood that the preceding is merely a detailed description of some 
examples and embodiments of this invention and that numerous changes to the disclosed 
embodiments can be made in accordance with the disclosure herein without departing 
from the spirit or scope of the invention. The preceding description, therefore, is not 
meant to limit the scope of the invention. 
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